Embodiments of the present invention relate to a method of routing application data in a Near Field Communication (NFC) system comprising an NFC interface circuit performing contactless data sending and receiving.
Embodiments of the present invention relate in particular to the routing of incoming application data received by the interface circuit.
Embodiments of the present invention globally relate to, the implementation of an NFC chipset as well.
NFC technology is currently developed by an industry consortium named NFC Forum (http://www.nfc-forum.org). The NFC technology derives from the Radio Frequency Identification (RFID) technology and uses NFC components having several operating modes, i.e., a “reader” mode, a “card emulation” mode, and a “device” mode (also called “device-to-device”). In the reader mode, the NFC component operates like a conventional RFID reader to read or write access an RFID chip (e.g., a chip card or contactless tag). The NFC component emits a magnetic field, sends data by modulating the amplitude of the magnetic field, and receives data by charge modulation and inductive coupling. In the “emulation” mode, described in European patent EP 1 327 222 in the name of the applicant, the NFC component operates in passively, like a transponder, to dialog with a reader and be seen by the other reader as an RFID chip. The NFC component does not emit any magnetic field, receives data by demodulating a magnetic field emitted by the other reader, and sends data by modulating the impedance of its antenna circuit (charge modulation). In the “device” mode, the NFC component must match another NFC component in the same operating mode, and each NFC component alternately places itself into a passive state (no field emission) to receive data and in an active state (with field emission) to send data.
In addition to these three operating modes (other operating modes may be designed in the future), an NFC component can implement several contactless communication protocols and is, for example, able to exchange data according to the ISO 14443-A protocol, the ISO 14443-B protocol, the ISO 15693 protocol, or the like. Each protocol defines a transmit frequency of the magnetic field, a method of modulating the amplitude of the magnetic field to send data in active mode, and a method of charge modulation by inductive coupling to send data in passive mode. An NFC component is therefore a multimode and multiprotocol device. The applicant, for example, markets an NFC component under the designation “MicroRead.”
Because of its wide communication capabilities, an NFC component is intended to be integrated in portable devices such as mobile phones or Personal Digital Assistant (PDA). An NFC chipset is therefore implemented as shown in FIG. 1, that is a set of chips comprising an NFC component (referenced “NFCR1”) and at least one first host processor HP1. “Host processor” designates any integrated circuit having a microprocessor or a microcontroller and which is connected to a port of the NFC component. In various applications, the NFC chipset also includes a second host processor HP2, and occasionally more.
The first host processor HP1 is the main processor of the device in which the NFC component is integrated, whereas the second host processor HP2 is a secure circuit. The host processor HP1 usually is a non-secure processor, for example, the baseband circuit of a mobile phone (or radiotelephony circuit). The host processor HP2 is for example, a Subscriber Identity Module (SIM) card (i.e., the micro controller present in a SIM card). The resources of the NFC component are therefore put at the disposal of the processors HP1, HP2 to allow the processors HP1, HP2 to manage contactless applications. Such applications are shown in FIG. 2, which represents a mobile phone 30 equipped with the NFC system (chipset) of FIG. 1. These applications are: (1) Applications of AP1 type: the NFC component of the mobile phone 30 is in “reader” mode to read or write access a contactless integrated circuit CLCT. In this case, the mobile phone is used like an RFID reader. This type of application can be free and be utilized for example, in reading advertising data inserted in a billboard of a bus shelter. The application can also require a fee and be utilized for example, in reading information reserved for subscribers. The application program AP1 is preferably held and executed by the processor HP1 if the service is free, or is preferably held and executed by the processor HP2 if the service requires the subscriber identification. Thus, as shown in FIG. 1, an application AP1 can be managed by the processor HP1 or the processor HP2. (2) Applications of AP2 type: the NFC component of the phone 30 is in “card emulation” mode to be read by conventional readers RD in pay access applications (e.g., payment machine, metro entrance, or the like). The mobile phone 30 is therefore used like a chip card. The application program AP2 is preferably held and executed by the secure processor HP2, as shown in FIG. 1, because the access to the service requires the subscriber identification. (3) Applications of AP3 type: the NFC component of the phone 30 is in “device” mode and dialogs with another device, for example, a reader integrated in another mobile phone 31 or in a computer 32. This type of application is usually free and allows data packets to be transferred from one device to another (point-to-point file transfer in particular). The application program AP3 is preferably held and executed by the non-secure processor HP1, as shown in FIG. 1, which has a computing power higher than the secure processor HP2 if it is a processor of a SIM card.
Thus, the implementation of an NFC chipset requires the provision of routing (conveying) data flows between each processor HP1, HP2 and the NFC component (data sent via the contactless data transmission channel) and incoming data flows (data received via the contactless data transmission channel) between the NFC component and each processor HP1, HP2. As a result, some practical problems are encountered, which will be understood by referring to FIGS. 3A, 3B.
FIG. 3A schematically shows the architecture of the NFC component. The NFC component includes an interface circuit CLINT for contactless data sending/receiving, equipped with an antenna circuit ACT, wire communication interfaces INTL INT2 linked to the interface circuit CLINT, and a controller NFCC. The interface INT1 is connected to the host processor HP1, and the interface INT2 is connected to the host processor HP2. All of these elements form an NFC chipset.
FIG. 3B shows data flows which must be routed so that the resources of the interface circuit CLINT can be used by each processor HP1, HP2. For the sake of simplicity, the interface circuit CLINT is assumed to be able to send or receive data according to three protocols PT1, PT2, PT3 only, for example ISO 14443-A, ISO 14443-B and ISO 15693, and has the three aforementioned operating modes M1, M2, M3 (“reader” mode, “emulation” mode, and “device” mode). Four different types of data flows are thus distinguished: (1) an outgoing data flow DT1out(Mi, PTi) from a source point P1 located in the processor HP1, transmitted to a destination point Pc located in the interface circuit CLINT, and transmitted by the interface circuit CLINT in a contactless data transmission channel created according to a protocol PTi (PT1, PT2 or PT3) and an operating mode Mi (M1, M2 or M3); (2) an outgoing data flow DT2out(Mi, PTi) from a source point P2 located in the processor HP2, transmitted to a destination point Pc located in the interface circuit CLINT, then transmitted by the interface circuit CLINT via a contactless data transmission channel created according to a protocol PTi and an operating mode Mi; (3) an incoming data flow DT1in(Mi, PTi) received by the interface circuit CLINT via a contactless data transmission channel created according to a protocol PTi and an operating mode Mi, then transmitted by the interface circuit CLINT from a source point Pc to a destination point P1 located in the processor HP1; and (4) an incoming data flow DT2 in(Mi, PTi) received by the interface circuit CLINT via a contactless data transmission channel created according to a protocol PTi and an operating mode Mi, then transmitted by the interface circuit CLINT from a source point Pc to a destination point P2 located in the processor HP2.
As each outgoing data flow can be emitted in three operating modes M1, M2, M3 and according to three protocols PT1, PT2, PT3, nine different configurations are possible for each outgoing data flow (assuming that each mode Mi and protocol PTi combination is authorized). It is therefore insufficient that one processor HP1 or HP2 sends the outgoing data to the interface circuit CLINT. The processor must also specify, for each data string sent, the mode/protocol Mi/PTi configuration to be used by the interface circuit CLINT to transmit the data in a contactless data transmission channel.
When incoming data is received via a contactless data transmission channel by the interface circuit CLINT, the interface circuit CLINT as well as the controller NFCC do not necessarily know which host processor HP1, HP2 receives the data. Consequently, in previous art, the data was sent to both processors HP1, HP2, and the processor not concerned with the data was responsible for not responding.
A more elaborate method of routing incoming data is described in PCT application WO 2004/029860. The method uses, as means of routing incoming data, Application Protocol Data Unit (APDU) commands received via the contactless data transmission channel. However, the method requires new protocols to be developed to implement routing, meaning that the external element sending data in the contactless data transmission channel must specify, in the APDU commands, to which internal element (in particular which host processor) the data must be sent.
In various applications, the external element sending data is not designed to give routing indications regarding which processor receives the data. Routing is an internal feature linked to the fact that several processors of a same NFC chipset share the same interface circuit for contactless data sending/receiving. It is therefore unlikely that a universal routing protocol will be integrated in the near future into devices not complying with an NFC standard. For example, a conventional reader used for payment or access control applications sends commands for secret code authentication and/or checking to contactless chip cards. During an authentication, such a reader does not know if it dialogs with a true contactless card or with an NFC component in “card emulation” mode. Consequently, such a reader is not designed to transmit parameters allowing the application data it sends to be routed inside the NFC chipset.
It is therefore desirable to provide for routing of incoming data received by the interface circuit CLINT, in a simple and efficient way, without requiring the external element sending the data to manage the routing.
It is further desirable to control the data flows between the non-secure processor HP1 of the NFC chipset and the source or destination point Pc (contactless data sent or received via the interface circuit CLINT). These data flows correspond to NFC applications that service providers wish to control with the view of a commercial exploitation, despite the processor HP1 being unsecure. Preferentially, it is also desirable to control data flows between the non-secure processor HP1, other secure processors that can be part of the system, and the interface circuit CLINT.
To perform outgoing data routing while allowing the interface circuit CLINT to be configured in an adapted way, it has been suggested to provide a data transfer protocol “Host Controller Interface” (HCI) of “universal” type, enabling any type of host processor to supply data to be sent to the interface circuit CLINT, while specifying the configuration to be used (protocol PTi and operating mode Mi) to transmit the data in the contactless communication channel. Such a protocol HCI provides data frames, each data frame having header fields and data fields. The data fields include the information necessary for the control of the interface circuit CLINT, in particular fields specifying the start and destination points of the data, the operating mode, and the protocol to be used by the interface circuit CLINT.
However, the conventional protocol HCI provides data frames with long and complex header fields, requiring a considerable processing time before processing the actual data. This problem is called “overheading,” which means that extended frame headers overload data flows and affect data transmission time. These header fields of great size moreover require buffers of great size and a high computing power.
Thus, it is desirable to provide a method of routing data in an NFC chipset which is simple to implement and does not require header fields of great length.